자바스크립트 테스트 마스터하기: 견고한 애플리케이션을 위한 Jest 설정 및 커스텀 Matcher 활용

빠르게 변화하는 오늘날의 소프트웨어 환경에서 견고하고 신뢰할 수 있는 애플리케이션은 매우 중요합니다. 이러한 애플리케이션을 구축하는 초석은 효과적인 테스트입니다. 프론트엔드와 백엔드 개발 모두에서 지배적인 언어인 자바스크립트는 강력하고 다재다능한 테스트 프레임워크를 필요로 합니다. 페이스북이 개발한 Jest는 선두적인 선택지로 부상했으며, 제로 설정(zero-configuration) 방식, 강력한 모킹 기능, 뛰어난 성능을 제공합니다. 이 종합 가이드에서는 Jest 설정의 복잡한 부분을 깊이 파고들고 커스텀 Matcher(매처) 생성을 탐구하여, 여러분의 위치나 프로젝트 규모에 관계없이 자바스크립트 코드의 품질과 신뢰성을 보장하는 더 표현력 있고 유지보수하기 쉬운 테스트를 작성할 수 있도록 지원합니다.

왜 Jest인가? 자바스크립트 테스트의 글로벌 표준

설정과 커스텀 Matcher에 대해 알아보기 전에, 왜 Jest가 전 세계 자바스크립트 개발자들에게 필수 프레임워크가 되었는지 이해해 봅시다:

• 제로 설정(Zero Configuration): Jest는 놀라울 정도로 쉬운 설정을 자랑하며, 최소한의 설정만으로 테스트 작성을 시작할 수 있게 해줍니다. 이는 테스트 주도 개발(TDD)이나 행위 주도 개발(BDD) 방식을 채택하는 팀에게 특히 유용합니다.
• 빠르고 효율적: Jest의 병렬 테스트 실행과 캐싱 메커니즘은 빠른 테스트 주기에 기여하여 개발 중 신속한 피드백을 제공합니다.
• 내장된 모킹(Mocking): Jest는 강력한 모킹 기능을 제공하여 코드 단위를 분리하고 효과적인 단위 테스트를 위해 의존성을 시뮬레이션할 수 있습니다.
• 스냅샷 테스팅(Snapshot Testing): Jest의 스냅샷 테스팅 기능은 UI 컴포넌트와 데이터 구조를 검증하는 과정을 단순화하여 예상치 못한 변경 사항을 쉽게 감지할 수 있게 합니다.
• 훌륭한 문서와 커뮤니티 지원: Jest는 포괄적인 문서와 활발한 커뮤니티를 보유하고 있어 필요할 때 답을 찾고 도움을 받기 쉽습니다. 이는 다양한 환경에서 작업하는 전 세계 개발자들에게 매우 중요합니다.
• 넓은 채택률: 스타트업부터 대기업에 이르기까지 전 세계 기업들이 자바스크립트 애플리케이션 테스트를 위해 Jest에 의존하고 있습니다. 이처럼 광범위한 채택은 지속적인 개선과 풍부한 리소스를 보장합니다.

Jest 설정하기: 테스트 환경 맞춤화

Jest가 제로 설정 경험을 제공하지만, 프로젝트의 특정 요구에 맞게 사용자 정의하는 것이 종종 필요합니다. Jest를 설정하는 주요 방법은 프로젝트의 루트에 있는 `jest.config.js` 파일(또는 TypeScript를 사용하는 경우 `jest.config.ts`)을 통하는 것입니다. 몇 가지 주요 설정 옵션을 살펴보겠습니다:

`transform`: 코드 트랜스파일링

`transform` 옵션은 Jest가 테스트를 실행하기 전에 소스 코드를 어떻게 변환해야 하는지를 지정합니다. 이는 최신 자바스크립트 기능, JSX, TypeScript 또는 기타 비표준 구문을 처리하는 데 매우 중요합니다. 일반적으로 트랜스파일링에는 Babel을 사용합니다.

예시 (`jest.config.js`):

module.exports = {
  transform: {
    '^.+\.js$': 'babel-jest',
    '^.+\.jsx$': 'babel-jest',
    '^.+\.ts?$': 'ts-jest',
  },
};

이 설정은 Jest에게 `.js` 및 `.jsx` 파일은 `babel-jest`를 사용하고, `.ts` 파일은 `ts-jest`를 사용하여 변환하도록 지시합니다. 필요한 패키지(`npm install --save-dev babel-jest @babel/core @babel/preset-env ts-jest typescript`)가 설치되어 있는지 확인하세요. 글로벌 팀의 경우, 모든 지역에서 사용되는 적절한 ECMAScript 버전을 지원하도록 Babel이 설정되었는지 확인해야 합니다.

`testEnvironment`: 실행 컨텍스트 시뮬레이션

`testEnvironment` 옵션은 테스트가 실행될 환경을 지정합니다. 일반적인 옵션에는 `node`(백엔드 코드용)와 `jsdom`(DOM과 상호 작용하는 프론트엔드 코드용)이 있습니다.

예시 (`jest.config.js`):

module.exports = {
  testEnvironment: 'jsdom',
};

`jsdom`을 사용하면 브라우저 환경을 시뮬레이션하여 React 컴포넌트나 DOM에 의존하는 다른 코드를 테스트할 수 있습니다. Node.js 기반 애플리케이션이나 백엔드 테스트의 경우 `node`가 선호되는 선택입니다. 국제화된 애플리케이션으로 작업할 때는 `testEnvironment`가 대상 고객과 관련된 로케일 설정을 올바르게 시뮬레이션하는지 확인해야 합니다.

`moduleNameMapper`: 모듈 임포트 해결

`moduleNameMapper` 옵션을 사용하면 모듈 이름을 다른 경로에 매핑할 수 있습니다. 이는 모듈 모킹, 절대 경로 임포트 처리, 또는 경로 별칭 해결에 유용합니다.

예시 (`jest.config.js`):

module.exports = {
  moduleNameMapper: {
    '^@components/(.*)$': '/src/components/$1',
  },
};

이 설정은 `@components/`로 시작하는 임포트를 `src/components` 디렉토리로 매핑합니다. 이는 임포트를 단순화하고 코드 가독성을 향상시킵니다. 글로벌 프로젝트의 경우, 절대 경로 임포트를 사용하면 다양한 배포 환경과 팀 구조 전반에 걸쳐 유지보수성을 향상시킬 수 있습니다.

`testMatch`: 테스트 파일 지정

`testMatch` 옵션은 테스트 파일을 찾는 데 사용되는 패턴을 정의합니다. 기본적으로 Jest는 `.test.js`, `.spec.js`, `.test.jsx`, `.spec.jsx`, `.test.ts`, 또는 `.spec.ts`로 끝나는 파일을 찾습니다. 프로젝트의 명명 규칙에 맞게 이를 사용자 정의할 수 있습니다.

예시 (`jest.config.js`):

module.exports = {
  testMatch: ['/src/**/*.test.js'],
};

이 설정은 Jest에게 `src` 디렉토리와 그 하위 디렉토리 내에서 `.test.js`로 끝나는 테스트 파일을 찾도록 지시합니다. 테스트 파일에 대한 일관된 명명 규칙은 특히 크고 분산된 팀에서 유지보수성에 매우 중요합니다.

`coverageDirectory`: 커버리지 출력 지정

`coverageDirectory` 옵션은 Jest가 코드 커버리지 보고서를 출력할 디렉토리를 지정합니다. 코드 커버리지 분석은 테스트가 애플리케이션의 모든 중요한 부분을 다루고 있는지 확인하고 추가 테스트가 필요할 수 있는 영역을 식별하는 데 필수적입니다.

예시 (`jest.config.js`):

module.exports = {
  coverageDirectory: 'coverage',
};

이 설정은 Jest가 커버리지 보고서를 `coverage`라는 이름의 디렉토리에 출력하도록 지시합니다. 코드 커버리지 보고서를 정기적으로 검토하면 코드베이스의 전반적인 품질을 개선하고 테스트가 중요한 기능을 적절히 다루고 있는지 확인할 수 있습니다. 이는 특히 국제화된 애플리케이션에서 다양한 지역에 걸쳐 일관된 기능과 데이터 유효성 검사를 보장하는 데 중요합니다.

`setupFilesAfterEnv`: 설정 코드 실행

`setupFilesAfterEnv` 옵션은 테스트 환경이 설정된 후에 실행되어야 할 파일 배열을 지정합니다. 이는 모의(mock) 설정, 전역 변수 구성 또는 커스텀 Matcher 추가에 유용합니다. 이것이 커스텀 Matcher를 정의할 때 사용하는 진입점입니다.

예시 (`jest.config.js`):

module.exports = {
  setupFilesAfterEnv: ['/src/setupTests.js'],
};

이것은 Jest에게 환경이 설정된 후 `src/setupTests.js`에 있는 코드를 실행하도록 지시합니다. 다음 섹션에서 다룰 커스텀 Matcher를 등록하는 곳이 바로 여기입니다.

기타 유용한 설정 옵션들

• `verbose`: 콘솔에 상세한 테스트 결과를 표시할지 여부를 지정합니다.
• `collectCoverageFrom`: 코드 커버리지 보고서에 포함될 파일을 정의합니다.
• `moduleDirectories`: 모듈을 검색할 추가 디렉토리를 지정합니다.
• `clearMocks`: 테스트 실행 사이에 자동으로 모의(mock)를 지웁니다.
• `resetMocks`: 각 테스트 실행 전에 모의(mock)를 재설정합니다.

커스텀 Matcher 만들기: Jest의 단언(Assertion) 확장하기

Jest는 `toBe`, `toEqual`, `toBeTruthy`, `toBeFalsy`와 같은 풍부한 내장 Matcher 세트를 제공합니다. 그러나 특히 복잡한 데이터 구조나 도메인 특정 로직을 다룰 때, 단언을 더 명확하고 간결하게 표현하기 위해 커스텀 Matcher를 만들어야 할 때가 있습니다. 커스텀 Matcher는 코드 가독성을 향상시키고 중복을 줄여 테스트를 이해하고 유지보수하기 쉽게 만듭니다.

커스텀 Matcher 정의하기

커스텀 Matcher는 `received` 값(테스트 대상 값)을 받고 `pass`(단언 통과 여부를 나타내는 불리언)와 `message`(단언이 통과하거나 실패한 이유를 설명하는 메시지를 반환하는 함수) 두 속성을 포함하는 객체를 반환하는 함수로 정의됩니다. 숫자가 특정 범위 내에 있는지 확인하는 커스텀 Matcher를 만들어 봅시다.

예시 (`src/setupTests.js`):

expect.extend({
  toBeWithinRange(received, floor, ceiling) {
    const pass = received >= floor && received <= ceiling;
    if (pass) {
      return {
        message: () =>
          `expected ${received} not to be within range ${floor} - ${ceiling}`,
        pass: true,
      };
    } else {
      return {
        message: () =>
          `expected ${received} to be within range ${floor} - ${ceiling}`,
        pass: false,
      };
    }
  },
});

이 예에서는 `toBeWithinRange`라는 커스텀 Matcher를 정의합니다. 이 Matcher는 `received` 값(테스트 대상 숫자), `floor`(최소값), `ceiling`(최대값)의 세 가지 인수를 받습니다. Matcher는 `received` 값이 지정된 범위 내에 있는지 확인하고 `pass`와 `message` 속성을 가진 객체를 반환합니다.

커스텀 Matcher 사용하기

커스텀 Matcher를 정의했다면, 다른 내장 Matcher와 마찬가지로 테스트에서 사용할 수 있습니다.

예시 (`src/myModule.test.js`):

import './setupTests'; // 커스텀 Matcher가 로드되었는지 확인

describe('toBeWithinRange', () => {
  it('passes when the number is within the range', () => {
    expect(5).toBeWithinRange(1, 10);
  });

  it('fails when the number is outside the range', () => {
    expect(0).not.toBeWithinRange(1, 10);
  });
});

이 테스트 스위트는 `toBeWithinRange` 커스텀 Matcher를 사용하는 방법을 보여줍니다. 첫 번째 테스트 케이스는 숫자 5가 1에서 10 사이의 범위에 있다고 단언하고, 두 번째 테스트 케이스는 숫자 0이 같은 범위에 있지 않다고 단언합니다.

더 복잡한 커스텀 Matcher 만들기

커스텀 Matcher는 복잡한 데이터 구조나 도메인 특정 로직을 테스트하는 데 사용될 수 있습니다. 예를 들어, 배열에 대소문자를 구분하지 않고 특정 요소가 포함되어 있는지 확인하는 커스텀 Matcher를 만들어 보겠습니다.

예시 (`src/setupTests.js`):

expect.extend({
  toContainIgnoreCase(received, expected) {
    const pass = received.some(
      (item) => item.toLowerCase() === expected.toLowerCase()
    );
    if (pass) {
      return {
        message: () =>
          `expected ${received} not to contain ${expected} (case-insensitive)`,
        pass: true,
      };
    } else {
      return {
        message: () =>
          `expected ${received} to contain ${expected} (case-insensitive)`,
        pass: false,
      };
    }
  },
});

이 Matcher는 `received` 배열을 순회하며 각 요소를 소문자로 변환한 후, `expected` 값(역시 소문자로 변환됨)과 일치하는지 확인합니다. 이를 통해 배열에 대해 대소문자를 구분하지 않는 단언을 수행할 수 있습니다.

국제화(i18n) 테스트를 위한 커스텀 Matcher

국제화된 애플리케이션을 개발할 때, 텍스트 번역이 여러 로케일에서 정확하고 일관적인지 확인하는 것이 중요합니다. 커스텀 Matcher는 이 목적에 매우 유용할 수 있습니다. 예를 들어, 지역화된 문자열이 특정 패턴과 일치하는지 또는 주어진 언어에 대한 특정 키워드를 포함하는지 확인하는 커스텀 Matcher를 만들 수 있습니다.

예시 (`src/setupTests.js` - 키를 번역하는 함수가 있다고 가정):

import { translate } from './i18n';

expect.extend({
  toHaveTranslation(received, key, locale) {
    const translatedString = translate(key, locale);
    const pass = received.includes(translatedString);

    if (pass) {
      return {
        message: () => `expected ${received} not to contain translation for key ${key} in locale ${locale}`,
        pass: true,
      };
    } else {
      return {
        message: () => `expected ${received} to contain translation for key ${key} in locale ${locale}`,
        pass: false,
      };
    }
  },
});

예시 (`src/i18n.js` - 기본적인 번역 예시):

const translations = {
  en: {
    "welcome": "Welcome!"
  },
  fr: {
    "welcome": "Bienvenue!"
  }
}

export const translate = (key, locale) => {
  return translations[locale][key];
};

이제 테스트에서 (`src/myComponent.test.js`):

import './setupTests';

it('should display translated greeting in french', () => {
    const greeting = "Bienvenue!";
    expect(greeting).toHaveTranslation("welcome", "fr");
});

이 예는 `Bienvenue!`가 프랑스어로 된 "welcome"의 번역된 값인지 테스트합니다. 특정 국제화 라이브러리나 접근 방식에 맞게 `translate` 함수를 조정해야 합니다. 적절한 i18n 테스트는 애플리케이션이 다양한 문화적 배경을 가진 사용자들과 공감대를 형성하도록 보장합니다.

커스텀 Matcher의 이점

• 가독성 향상: 커스텀 Matcher는 특히 복잡한 단언을 다룰 때 테스트를 더 표현력 있고 이해하기 쉽게 만듭니다.
• 중복 감소: 커스텀 Matcher를 사용하면 공통 단언 로직을 재사용하여 코드 중복을 줄이고 유지보수성을 향상시킬 수 있습니다.
• 도메인 특정 단언: 커스텀 Matcher를 사용하면 도메인에 특화된 단언을 만들어 테스트를 더 관련성 있고 의미 있게 만들 수 있습니다.
• 향상된 협업: 커스텀 Matcher는 테스트 관행의 일관성을 증진시켜 팀이 테스트 스위트에서 협업하기 쉽게 만듭니다.

Jest 설정 및 커스텀 Matcher를 위한 모범 사례

Jest 설정과 커스텀 Matcher의 효과를 극대화하려면 다음 모범 사례를 고려하십시오:

• 설정은 간단하게 유지: 불필요한 설정을 피하세요. 가능할 때마다 Jest의 제로 설정 기본값을 활용하십시오.
• 테스트 파일 정리: 테스트 파일에 대한 일관된 명명 규칙을 채택하고 프로젝트 구조 내에서 논리적으로 정리하십시오.
• 명확하고 간결한 커스텀 Matcher 작성: 커스텀 Matcher가 이해하고 유지보수하기 쉬운지 확인하십시오. 단언이 실패한 이유를 명확하게 설명하는 유용한 오류 메시지를 제공하십시오.
• 커스텀 Matcher 테스트하기: 커스텀 Matcher가 올바르게 작동하는지 확인하기 위해 테스트를 작성하십시오.
• 커스텀 Matcher 문서화하기: 다른 개발자들이 사용 방법을 이해할 수 있도록 커스텀 Matcher에 대한 명확한 문서를 제공하십시오.
• 글로벌 코딩 표준 준수: 위치에 관계없이 모든 팀원 간의 코드 품질과 유지보수성을 보장하기 위해 확립된 코딩 표준과 모범 사례를 준수하십시오.
• 테스트에서 현지화 고려: 로케일별 테스트 데이터를 사용하거나 i18n용 커스텀 Matcher를 만들어 다양한 언어 설정에서 애플리케이션을 적절히 검증하십시오.

결론: Jest로 신뢰할 수 있는 자바스크립트 애플리케이션 구축하기

Jest는 자바스크립트 애플리케이션의 품질과 신뢰성을 크게 향상시킬 수 있는 강력하고 다재다능한 테스트 프레임워크입니다. Jest 설정과 커스텀 Matcher 생성을 마스터함으로써 프로젝트의 특정 요구에 맞게 테스트 환경을 조정하고, 더 표현력 있고 유지보수하기 쉬운 테스트를 작성하며, 코드가 다양한 환경과 사용자층에서 예상대로 작동하는지 확인할 수 있습니다. 작은 웹 애플리케이션을 구축하든 대규모 엔터프라이즈 시스템을 구축하든, Jest는 글로벌 고객을 위한 견고하고 신뢰할 수 있는 소프트웨어를 구축하는 데 필요한 도구를 제공합니다. Jest를 받아들이고 자바스크립트 테스트 관행을 새로운 차원으로 끌어올려, 애플리케이션이 전 세계 사용자를 만족시키는 데 필요한 표준을 충족한다는 자신감을 가지십시오.